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SUMMARY 

While preparatory activities for a first-generation European Data Relay Satellite System (DRSS), due lor 
deployment in 1998, are currently being performed, investigations are also taking place to define the technologies and 
the architectures for advanced DRSSs, featuring the absence of zone-of-exclusion, improved European regional 
coverage and a high level of interconnectivity and flexibility. The main challenges for such a system are to accomodate 
a large variety of users, with different requirements in terms of data volumes, bit-rates, service character! sties, etc., and 
to provide a high degree of flexibility in routing data through the various network links. 

Maior advances in terms of on-board mass and power savings are expected for digital devices in the next 
decade, while the same may not occur for RF devices. It is considered appropriate then to exploit the Possibles i offered 
by technology and to propose the use of an On-Board Processor (OBP) aboard each satellite of the DRSS. OBP al o s 
the system designer to individually optimise the various link parameters, to achieve full interconncctiy lty and flexibility, 
to accept and process data structures having different multiplexing formats, to terminate useless information (namely 
"idle frames") on-board and to simplify optical links operation and design. 

After introducing a possible DRSS topology and network architecture, the paper discusses an asynchronous 
network concept, whereby each link (Inter-orbit, Inter-satellite, Feeder) is allowed to operate on its own clock, without 
causing loss of information, in conjunction with packet data structures, such as those specified by the CCSDS lor 
advanced orbiting systems. The paper then describes a matching OBP payload architecture, highlighting the advantages 
provided by the OBP-based concept and then giving some indications on the OBP mass / power requirements. This 
paper is derived from the results of a study performed under a European Space Agency contract. 


INTRODUCTION 

The European Space Agency (ESA) has in place a number of development programs aimed at establishing 
an autonomous European manned presence in-orbit. These programs include the development of the Hermes Manned 
Reusable Space Plane, the Columbus Pressurised Module (an integral part of the International Space Station Freedom), 
and a Man Tended Free Hying Laboratory. To support the communication requirements of these and other programs, 
ESA is also developing a Data Relay Satellite System (DRSS) similar to the American TDRS system. The European 
DRSS is planned to be operational by 1998. 

In parallel with this activity, ESA has initiated studies which seek to plot out the strategic future of the In-orbit 
Communications Infrastructure required to support the space programs of the next century. In this paper, we discuss 
some of the results of such a study into a future Space Communications Network (SCN), focussing in particular on one 
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key result, namely the importance of On-Board Processing (OBP) to the success of such a system The time frame under 
consideration is 2000 - 2035. 



Fig. 1 Present DRSS topology 


Before discussing the "near-earth" part of the 
SCN, we first outline the current DRSS concept. 
The present DRSS topology is shown in fig. 1 . The 
system consists of two Data Relay Satellites 
(DRSs) placed at 44 deg. West, and 59 deg. East. 
Each DRS carries a Feeder Link (FL) at Ka-band 
(20/30GHz), and Inter-Orbit Link (IOL) accesses 
at S-band, Ka-band (23/27GHz), and at optical 
frequencies (0.8pm), the latter being provided on 
apre-operational basis. Discussions are ongoing at 
this time to ensure interoperability with current 
S-band services on TDRS. and future Ka-band and 
possible optical services on advanced TDRS. As 
with the TDRS system, a zone of exclusion exists 
around the far side of the earth, where communica- 
tions is not possible with cither DRS. This zone 
extends up to several thousand kilometers altitude 
for the current DRSS configuration. 


AN ADVANCED TOPOLOGY FOR FUTURE DRSSs 

In the SCN definition activity, lorecasts were produced for the number and type of space programs likely to 
be undertaken in the timescale under consideration. These forecasts considered every type of space activity from 
expendable and reusable launchers, through to large space stations and industrial activities. We can summarise the main 
findings ot the study as follows: /- the nominal growth scenario projected 19 user satellites of the SCN by 2015, and 
33 by 2035, //- each user would require continuous communications with minimal interruption resulting only from link 
handover, in- standard space link access rates would be defined compatible with bearer services available to users on 
the ground and the delivery ol data should be transparent to the network interworking process; iv- the system should 
seek to deliver data to the ground users in the most cost-effective manner possible. 

The reference near-earth SCN configuration, 
selected among a number of topologies traded-off 
against each other, is shown in fig. 2. 

It consists of three DRSs (30 deg. E, 10 deg. W.and 
170 deg. W), the first two carrying IOL, Inter-Satel- 
lite Link (1SL), and FL payloads and the last one 
carrying only IOL and ISL terminals. This con- 
figuration provides total global coverage for the 
space users with no zone-of-exclusion. 

From DRS3, connection is made via ISL to one of 
the two DRSs over Europe for data to be 
downlinked to the ground. Alternative routing 
paths are feasible with the Pacific DRS having a 
choice of European DRSs to crosslink to, and each 
of the European DRSs having the ability to 
crosslink data onto cither FL. 


SPACE LINKS TRADE-OFFS 

Technologies for the implementation of each of the link types (IOL, ISL, FL) were studied. The following 
conclusions were am ved at: /- the FL should continue to be implemented at Ka-band; ii- ISL's would be most efficiently 
implemented at optical frequencies; iii- IOL’s would be a mix of optical and S-band technology. The reasons behind 
this last decision were that S-band is the most appropriate technology to service those space users requiring low data 


DRS3 
170 deg. W 



Fig. 2 The reference near-earth SCN topology 
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rate and having omni-directional antennas. All higher data rate services would be best served by a single technology, 
leading to a homogeneity of IOL terminals, or accesses, on the relay spacecraft. Given the rapid advances that are now 
taking place in optical technology and terminal design and the inherent limitations of RF technologies, it was 
recommended that the technology used here should be optical. The decision to go optical was re-enforced by the Findings 
that the network would of necessity be regenerative. This requirement arose from the findings on phase noise present 
in millimetre wave and coherent optical systems. This precludes the transparent carriage of low data rate services, 
baseband multiplexing of these services is therefore required at the DRS. Given this, there is a very little penalty and 
great benefits to be gained from making the whole system regenerative. 

The size of the payload on each DRS is critically depen- 
dent on the number of IOL terminals provided. This in turn 
is a function of the grade of service offered to the users in 
terms of access availability when a link is requested. Tab. 
1 shows the relationship between link availability and 
number of accesses provided on the 170 deg. W space- 
craft. It shows that, fora link availability of 99.9%, 26 IOL 
terminals are required, on each DRS, for year 2035. 

Of course, this availability is realised only if any user can access any terminal and obtain the service he requires. 
It is not sufficient simply to provide terminals of the same technology. Homogeneity of data rates is also required. To 
address this issue, three levels of data rates were defined (see tab 2). The first is the space link data rate, defined as the 
data rate of the service between user and relay spacecraft, including CCSDS packet protocol overheads. The user data 
rate is that rate which is generated from the instrument or unit on board the user spacecraft. 

The electrical rate is the rate which results in the ground 
network, in this case ISDN, after encapsulation of the 
CCSDS packet. Additionally, it was recognised that many 
users require more than a single service or channel. Thus 
services from the user spacecraft arc multiplexed onto 
higher rate bearers. There are many such schemes for 
defining these bearers. One such scheme provides for three 
IOL bearer rates carrying combinations of the services 
offered, i.c.: 1.672 Mbps (1 .5552 Mbps + 2*5 1 .84 Kbps + 
12.96 Kbps ), 30.1 13 Mbps (28.35 Mbps + 1.5552 Mbps + 
3*51.84 Kbps + 4*12.96 Kbps) and 126.865 Mbps (\26.36 
Mbps + 9*51.84 Kbps + 3*12.96 Kbps). 

The implications of introducing a scheme such as this is that each terminal is then designed to operate at three 
standard bearer rates. At the same time no user has to dramatically oversize his terminal package, as the size and mass 
of an optical IOL terminal is a weak function of data rate. The OBP package can then operate on the received data 
stream and demultiplex and route services as and when required. 

The ISL between relay spacecrafts carries a single high data rate multiplex on an optical carrier. Thus, the 
OBP has complete flexibility on how it orders packets and services. With the user community discussed above, it is 
conceivable that data rates of up to l.IGbps could be required on ISLs. 

The FLs are assumed to be multi-channel links, with each channel carrying up to 140Mbps. This is considered 
to be the maximum feasible for Ka-band High Power Amplifiers, given the projected development of this technology 
over the timescale under consideration. 
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16 Kbps 

11.06 Kbps 

12.67 Kbps 

12.96 Kbps 

64 Kbps 

44.24 Kbps 

50.67 Kbps 

51.84 Kbps 

1.92 Mbps 

1.327 Mbps 

1 ,520 Mbps 

1.5552 Mbps 

35 Mbps 

24.19 Mbps 

27.7 Mbps 

28.35 Mbps 

156 Mbps 

107.83 Mbps 

123.5 Mbps 

126.36 Mbps 


Tab. 2 Data rates on the various SCN segments 


Probability 

99.9% 

99.5% 

95% 

90% 

Accesses 

2015 

17 

16 

14 

13 

Accesses 

2035 

26 

25 

22 

21 


Tab. 1 Availability vs. number of accesses 


THE ASYNCHRONOUS NETWORK CONCEPT 

In the system architecture previously illustrated, the function of the OBP is that of ensuring the proper routing 
(to an IOL or an ISL or a FL) of the individual communications channels multiplexed over digital streams, operating 
at different bit-rates. Typically, the need for synchronisation of all such streams would exist, as frame start epochs have 
all to appear properly aligned at the on-board switch inputs. In previous study activities, it was demonstrated that the 
synchronisation schemes required for systems based upon multiple satellites interconnected by ISLs are very complex 
and may also suffer reliability problems. 
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An alternative approach is that of adopting an asynchronous network concept, which is particularly suitable 
when operating with packet communications structures. According to this concept, the on-board switch and the various 
links independently operate on their own clocks, which are necessarily not identical to one another. Information loss is 
prevented by the presence of useless or "idle" frames in the data stream. These are transmitted whenever there is no 
useful information to be delivered, for the sole purpose of maintaining the receiver synchronisation. 

In many cases, the presence of idle frames is guaranteed by the natural traffic statistics. Their number can 
also be increased, should it be required, by overdimensioning the multiplexed stream rate. An overdimensioning will 
anyway result from the fact that only "standard" bit rates are allowed in the IOLs, as discussed before. 

With this scheme, it also becomes possible to dimension the various links taking advantage of the fact that 
idle frames can be terminated at the OBP, thus increasing the links fill factor, especially in presence of services having 
a bursty nature. 


CONSISTENCY WITH CCSDS-STANDARD STRUCTURES 

For an SCN to be implemented in the lirst decades of the next century, it seems appropriate to propose the 
adoption of the communications structures specified by the Consultative Committee for Space Data Systems (CCSDS). 

Consistent with CCSDS specifications, the communications structures which have been considered are 
transfer frames, each of which comprises one or more telemetry packets, which are in close relation with the source 
packets generated by user’s instruments. The transfer frames, which are optionally Recd-Solomon encoded, constitute a 
time-continuous stream, so that idle frames are generated when there is no outstanding telemetry packet to be transmitted. 
Dedicated sequences of transfer frames, not necessarily adjacent to each other, are assigned to carry selected groups of 
source packets. These are called virtual channels. 

CCSDS links are typically point-to-point links. In the proposed SCN, which adopts multiplexing techniques 
on all links, interleaving of information generated by different entities (spacecrafts, ground stations) will necessarily 
occur. It may be difficult to keep the interleaving pattern under control, it being also dependent on the information 
statistics. However this is not expected to be a basic problem , because transfer frames are protocol data units independent 
of each other, in the sense that interleaving of transfer frames of different virtual channels, even if generated by different 
spacecrafts and/or ground stations, is possible without conflicting with the CCSDS protocol. 

Several issues had to be addressed for ensuring the possibility of implementing the desired OBP features and 
for verifying their consistency with CCSDS specifications. Problems relevant to the availability of routing information, 
to the segmentation of the overall link protocol and to the termination of idle packets on-board were considered in the 
study, coming to the conclusion that acceptable solutions can be found to each of them. It was determined that no 
higher-layer functions (e.g. error correction) shall be provided by the OBP. These will be implemented in the end-to-end 
protocols. Independent and consecutive frame counts shall be used on each link section. To allow the on-board 
termination of idle frames, the OBP shall not only operate at transfer frame level, but it shall also examine the content 
of the transfer frame data field, to interpret the header of the embedded telemetry packets. 

As to the transfer frame length, this shall be equal 
for all frames, to simplify the on-board switch 
design. This does not pose any constraint, as 
CCSDS specifications indicate the transfer frame 
length as a mission set-up parameter. It was con- 
sidered very appropriate that the telemetry packets 
length be selected such that an integer number of 
telemetry packets can be fitted within the transfer 
frame data field (the CCSDS-specified 
"synchronous" insertion). In particular, it is 
proposed that only one telemetry packet, compris- 
ing a48-bit header and a 6,960-bit (or 870 octects) 
data field, be fitted within the transfer frame data 
field. The resulting transfer frame arrangement is 
shown in fig. 3. 
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Note: field lengths are expressed in symbols 

Fig. 3 Proposed transfer frame structure 
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THE OBP PAYLOAD 


The SCN svstem supports two logical capacity flows of very different size, i.e. the Forward-Link (FWL) and 
. i in v } traffic The inbound and the outbound sections of an ISL will both have to support FWL and 

single OBP S cl" the FWL and me RTL. has been considered. Overall.lhe OBP can 

tellhll an on-boa* subsystem having ihe capability of ° P 

streams (IOLs, ISLs, FLs), operating at different bit-rates and composing CCSDS -standard frames. 


OBP Dorts 

IOL 

ISL 

FL 

Input 

n@ 13 Kbps 
9 @1.7 Mbps 
4 @ 31 Mbps 
13 (a) 127 Mbps 

2 @ <11 Gbps 

1 @ 31 Mbps 

Output 

3 @ 13 Kbps 
17 @52 Kbps 
6 @ 1.7 Mbps 

2 @ <1.1 Gbps 

5 @ 127 Mbps 


Tab. 3 OBP capacity requirements 


The OBP shall be capable of terminating idle 
frames and of routing all other incoming frames to 
the appropriate output ports. The number of 
streams to be handled by the OBP is shown in tab. 
3 (rounded bit-rate figures are indicated). The 
number of 13 Kbps IOL streams remains TBD; 
nevertheless this has a minor impact on the OBP 
design. The general OBP block diagram , presented 
in fig. 4, was developed considering that the same 
design shall be consistent with both the DRS1/2 
and DRS3 operational modes. The high-level func- 
tions visualised in the block diagram are: 


Demodulators , which handle the incoming IF signals (signals travelling over .optical links, namely ISLs and the 
high-rate IOLs, are not to be demodulated, the interface with the OBP being at baseband level). 

Demultiplexers operating on ISLs only. Eight 127 Mbps streams are derived out of each aggregate high-rate (up * to 
1 1 Gbps) ISL stream (a bit-by-bit multiplexing strategy is adopted to minimise memory requirements). Unique 
are inserted, at multiplexed stream level, to allow the required alignment function. 

Decoders (Reed-Solomon), operating on the transfer frames (the attached synchronisation marker is not encoded), 
utilising the appended check symbols. The Decoders, although placed in front of the Synchronisers (next item), have 
m Srm anEunent function, to detect the Start Of Transfer Frame (SOTF flag) within the received stream. Only 
the transfer frameTare to be delivered to the Synchronisers, filling the inter-transfer frame gap (due to the missing 
synchronisation marker and check bit fields) with "don’t care bits. 

Synchronisers used to align the incoming transfer frames to the unique on-board frame clock (127 Mbps units) and 

' to also SS rate conversion ( 1 3 Kbps 1 .7 Mbps and 3 1 Mbps units). All streams exiting the Synchronisers operate 
at 127 Mbps A FIFO-based buffer/alignment device, written with the incoming stream clock and read with the 
onboard clock is used to align frames. To counteract the effect of situations where the incoming frame clock rate is 
higher than the on-board one, it is necessary to terminate some idle frames before they are slo i I " ct | ' n j lc ' f 
Synchronisers shall therefore incorporate logic able to read the header of the telemetry packet embedded m the transfer 
fnune and to accordingly control the FIFO writing operations. They also have to interpret the transfer frame header, 
Strafing a^ ^TrSr Fraine Designator (TFD) for each transfer frame. The TFD contains information on both 
the frame destfnation-entity (derived from the transfer frame header) and on whether a frame is idle or not (derived 
from the telemetry packet header). 

- Input Frame Processors, having the main tasks of generating a Routing Code (RC), subsequently used by^e 
Switching Module to route individual frames to the appropnate output port, and of attaching it in front of each transfer 
Se ™ place of to previously tenninated CCSDS synchronisation marker. The RC is a short sequence which 
unambiguously designates one specific Switching Module output port. The RC is determined on the basis of the TFD 
nattem and the network route (i.e. direct to a FL or via an ISL) to be followed by each transfer frame to reach the 

destination entity. This association, decided by the Operations Control Ce ^ ( ^ } e QCCvia a comroVchaSSl 
contained in the On-board Control Unit (OCU), written and periodically updated by the OCC, via a control channel. 

- Switching Module which routes the incoming 127 Mbps frames to the appropriate output port. Like switches used 
for terrestrial ATM applications, it shall be able to provide internal buffering functions, intended to solve conflicts 
of frames appearing at different inputs but having the same destination port. Each transfer frame has t0 he hand e 
by the Switching Module preserving the sequencing of frames belonging to the same virtual channel and reducing, 
as far as possible, the switching delays and their spread. 
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Switching Fabric 
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Fig. 4 OBP subsystem functional diagram 







-SSSSSSSSSi^pS^ 

SK? is s * up 'or when it has to be rerouted for inter-satellite v.sib.hty problems. 


OBP IMPACT ON PAYLOAD IMPLEMENTATION 

From the analyses performed, it was possible to preliminarily evaluate the main OBP parameters, as shown in tab. 4 


Year 

1990 

Technology 

commercial 

Power (W) 

Weight (KrL 

Structure 

185 

74 

assembly 

2015 

qualified 

4 

1.5 

board 

2035 

aualified 

0.12 

n.a. 

chip 


Tab. 4 OBP capacity requirements 


The most interesting result is the effect of components 
integration. With today technology, the OBP assumes 
the aspect of an assembly; however it is expected that, 
via a massive utilisation of ASIC devices, the OBP can 
become a simple board in 2015 or even a single chip in 
2035. The OBP impact on the overall payload becomes 
then virtually negligible. 


CONCLUSIONS 

This paper considers the applicability of OBP techniques to an advanced DRSS, constituting the near-earth 
part of the SCN. OBP has been found to be beneficial with regard to the. 

- Oeeral, nepeork performance. The pa> loads uiihsed 

requirements. OB P p can accomodate all such requiremenis, allowing, 
in addition, to terminate useless infonnation on-board. 

- NeM ork synckromsanon. A fotmidable : problem .is 

for the interface bet ween the ISL and the other payload sub-systems. 

The CCSDS standard has been reviewed and it has been found that, by appropriate selection of parameters, 
there are no basic inconsistencies between it and the OBP operational mechanisms. 

An OBP payload operating in an ,5^ 

Fabric realised with the same techniques which w rtrveloDments the OBP has been tentatively sized 

(B-ISDN). After a review of present techno .logy ^ implementable with neglcctable 

rmpa^n t FaWoTma^ Z iS’wenwhilc ptwfding important heneftL, with regard to overatl system efficiency. 
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